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REMARKS 

Applicant respectfully requests reconsideration of the present application in view of 
the foregoing amendments and in view of the reasons that follow. 

In the outstanding final Office Action of July 18, 2008, the Examiner asserted that 
claims 8-20 were rejected under 35 U.S.C. § 101 because the claimed invention is allegedly 
directed to non-statutory subject matter. Applicant traverses the rejection for the reasons set 
forth below. 

With regard to claims 8-20 of the present application, the Examiner continues to 
maintain that: 

Regarding claim 8, recites a device but it appears reasonable to 
interpret this device by one of ordinary skill in the art as 
software, per se. Applicant's specification provides no explicit 
and deliberate definition of the components such as consumer 
application, provider application and applicant interworking 
framework that make up the device other than they are software 
components, which are directed to functional descriptive 
material, per se, and are therefore nonstatutory. 

Applicant's responses dating back to May 14, 2007 repeatedly presented arguments 
indicating that, contrary to the Examiner's assertions, the subject matter recited in claims 8- 
20 of the present application are statutory in light of 35 U.S.C. § 101 . In the July 24, 2007 
Final Office Action, the Examiner again rejected claims 8-20 under 35 U.S.C. § 101, 
maintaining that the subject matter recited therein is nonstatutory, without answering and/or 
rebutting any of Applicant's previous arguments. In response to the July 24, 2007 Final 
Office Action, Applicant submitted a Pre -Appeal Brief Request for Review on October 24, 
2007 again discussing at length why claims 8-20 of the present application recite statutory 
subject. Applicant was informed on November 30, 2007 that prosecution would be reopened 
and a new Office Action would be issued. However, claims 8-20 were again rejected under 
35 U.S.C. § 101 in the January 24, 2008 non-final Office Action, where once again, the 
Examiner failed to respond substantively to any of Applicant's arguments regarding this 
rejection. Furthermore, in Applicant's April 24, 2008 Reply, Applicant indicated the 
Examiner's failure to respond to Applicant's arguments regarding this rejection. In the 
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outstanding Office Action, the Examiner responded solely to an alternative argument 
presented by Applicant as to why claims 8-20 are statutory, while completely ignoring 
Applicant's previously presented arguments and the majority of Applicant's latest arguments 
in the April 24, 2008 Reply, and still issuing a final Office Action. 

Yet again, and in light of the Examiner's repeated rejection of claims 8-20 under 35 
U.S.C. §101, Applicant directs the Examiner to Section 707.07(f) of the MPEP which states 
that "[W]here the applicant traverses any rejection, the examiner should, if he or she repeats 
the rejection, take note of the applicant's argument and answer the substance of it. " 
(emphasis added). In this instance, although the Examiner maintained his rejection, he failed 
to substantially answer or rebut Applicant's arguments or further provide evidence to support 
his position that claims 8-20 of the present application recite nonstatutory subject matter. 
Therefore, Applicant respectfully submits that the outstanding final Official Action, as well 
as the previous non-final Office Action of January 24, 2008 are improper with respect to 
claims 8-20 in that it is unresponsive to Applicant's arguments and in violation of Section 
707(f) of the MPEP. 

Additionally, Applicant incorporates herein by reference in their entirety those 
arguments directed to claims 8-20 filed in Applicant's previous response of May 14, 2007 at 
pages 2-4, in Applicant's previous Pre -Appeal Brief Request for Review of October 24, 2007 
at pages 1-3, and in Applicant's Reply of April 24, 2008 at pages 2-3. That is, the present 
application is replete with references to menu service interfaces, user interfaces (UI), menu 
items, phones, etc. upon which the various embodiments described in the present application 
can be implemented. (See, e.g., Figures. 2 and 5, Para. [0004], [0030], [0038], [0040], 
[0044], [0046], and [0061] of the present application). Therefore, it should be abundantly 
clear that the methods described in claims 1-20 are not software per se, and therefore, 
contrary to the Examiner's assertions, do meet the statutory requirement(s) of 35 U.S.C. 
§101. Moreover, Applicant submits that the processes described in, e.g., claims 8-20 of the 
present application are "acts" that are being performed. Applicant is at a loss to how any 
other characterization can be given to a method, other than acts that are performed. 
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Additionally and for example, independent claim 8 is directed to "a device" that 
comprises, e.g., a consumer application, at least one provider application, and an application 
interworking framework. The Examiner's position that claims 21-23 of the present 
application (which recite a computer program product, embodied on a computer-readable 
medium), are statutory is telling. That is, Applicant submits that the Examiner has already 
admitted that the consumer and provider applications as well as the application interworking 
framework are "functional descriptive material." (See, e.g., page 8 of the outstanding Office 
Action). However, it appears that the Examiner's interpretation of Section 2106.01 of the 
MPEP is flawed. That is, the Examiner asserted at page 8 of the outstanding Office Action 
that: 

Applicant's specification provides. . . consumer application, 
provider application and application interworking framework 
that make up the device. . . which are directed to functional 
descriptive material, per se, and are therefore non-statutory. 

It appears that the Examiner's position is that "functional descriptive material" is "per 
se non-statutory" because the Examiner has interpreted the claimed applications/framework 
as being descriptive material. However, Section 2106.01 of the MPEP does not support such 
an interpretation. That is, Section 2106.01 of the MPEP indicates the following: 

Descriptive material can be characterized as either "functional 
descriptive material" or "nonfunctional descriptive material." In 
this context, "functional descriptive material" consists of data 
structures and computer programs which impart functionality 
when employed as a computer component . (The definition of 
"data structure" is "a physical or logical relationship among 
data elements, designed to support specific data manipulation 
functions." The New IEEE Standard Dictionary of Electrical 
and Electronics Terms 308 (5th ed. 1993).) "Nonfunctional 
descriptive material" includes but is not limited to music, 
literary works, and a compilation or mere arrangement of data. 

Both types of "descriptive material" are nonstatutory when 
claimed as descriptive material per se, 33 F.3d at 1360, 31 
USPQ2d at 1759. When functional descriptive material is 
recorded on some computer-readable medium, it becomes 
structurally and functionally interrelated to the medium and 
will be statutory in most cases since use of technology permits 
the function of the descriptive material to be realized. Compare 
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InreLowry, 32 F.3d 1579, 1583-84, 32 USPQ2d 1031, 1035 
(Fed. Cir. 1 994)(discussing patentable weight of data structure 
limitations in the context of a statutory claim to a data structure 
stored on a computer readable medium that increases computer 
efficiency) and>Inre< Warmerdam, 33 F.3d *>1354,< 1360- 
61, 31 USPQ2d *>1754,< 1759 (claim to computer having a 
specific data structure stored in memory held statutory product- 
by-process claim) with Warmerdam, 33 F.3d at 1361, 31 
USPQ2d at 1760 (claim to a data structure per se held 
nonstatutory), (emphasis added). 

In other words, the MPEP is clear in that determining whether or nor descriptive 
material (both non-functional and functional) is based upon "how" that descriptive material is 
claimed. That is, functional descriptive material can be both statutory and non-statutory 
depending upon whether or not that descriptive material is claimed as descriptive material per 
se. The MPEP does not in any suggest that once subject matter is deemed to be descriptive 
material, it is automatically non-statutory. 

In light of the above, the MPEP, quite contrary to the Examiner's position, indicates 
that functional descriptive material, when recorded on computer readable medium, becomes 
statutory. In this instance, Applicant has repeatedly presented arguments and evidence that 
clearly suggest that the claimed limitations of claims 8-20 directed to, e.g., consumer 
applications, provider applications, and application interworking frameworks, are recorded 
on computer readable medium/implemented on some physical device/hardware. Claim 8 for 
example is clearly directed to a device, where the device comprises such applications and 
frameworks. Contrary to the Examiner's assertions at page 3 of the outstanding Office 
Action, Applicant submits that a device comprising such applications and/or frameworks 
suggests that such applications and/or frameworks are realized on some type of computer 
readable medium/hardware. Because the Examiner has already admitted that the limitations 
at issue are "functional descriptive material" and because the MPEP is clear in that functional 
descriptive material when, e.g., structurally/functional interrelated to, e.g., some computer 
readable medium, claims 8-20 of the present application are directed to statutory subject 
matter per the requirements of 35 U.S.C. § 101. 

Further still, Applicant previously submitted that even if the claimed subject matter 
of, e.g., claims 8-20 could be characterized as software per se, the subject matter is not 
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automatically deemed to be non- statutory subject matter because they recite methods that 
produce concrete, tangible, useful results in accordance with State Street Bank & Trust v. 
Signature Financial Group, Inc. 149 F.3d 1368, 47 USPQ2d 1569 (Fed. Cir. 1998). This 
mention of the State Street decision was presented in Applicant's May 14, 2007 Reply in 
response to the Examiner's assertions at page 4 of the March 12, 2007 Office Action that 
claim 8-16 allegedly raised questions as to whether a concrete, useful, and tangible result was 
produced. In the July 24, 2007 final Office Action, the Examiner maintained the rejection of 
claims 1-20 under 35 U.S.C. § 101 without addressing whether Applicant's arguments 
regarding the production of a concrete, useful, tangible result were persuasive. Thus, 
Applicant re-asserted the argument at page 3 of Applicant's Pre-Appeal Brief Request of 
October 24, 2007. In the January 24, 2008 Office Action, Applicant again was unaware 
whether or not the Examiner was persuaded by Applicant's arguments regarding the concrete, 
useful, tangible result, and hence, again made mention of that argument which references the 
State Street decision in Applicant's April 24, 2008 Reply. Therefore, contrary to the 
Examiner's assertions at page 3 of the outstanding Office Action, the Examiner did in fact 
make assertions alluding to producing a concrete, tangible, useful result as forming at least a 
part of a basis for statutory subject matter. {See, e.g., page 4 of the March 12, 2007 Office 
Action). 

Lastly, Applicant notes with interest that at page 7 of the outstanding Office Action, 
the Examiner indicated the following: 

Every application stored in a device is considered as integrated 
into the device because it is part of the device. In this case, UI 
41 is part of the device and therefore it must be integrated into 
the device with other software applications of the device. 

That is, the Examiner appears to be admitting that Applicant's characterization of at 
least the statutory aspect of claims 8-20 as described above is correct, i.e., an application, if 
associated with a device is integrated thereon, and not merely some piece of abstract 
software. 1 



1 It should be noted that Applicant is in no way suggesting that the Examiner's assertion is valid for the 
purpose with which the Examiner made the assertion. That is, Applicant is not admitting that Hayton et al. 
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Claims 1-3 and 5-23 were rejected under 35 U.S. C. § 102(b) as being anticipated by 
U.S. Patent No. 7,194,743 (Hayton et al.) Applicant traverse the rejection for the reasons set 
forth below. 

With regard to independent claims 1,8, and 17 of the present application, the 
Examiner asserted that Hayton et al. teaches all of the required limitations recited therein. 
Applicant disagrees. Additionally and at page 3 of the outstanding Office Action, the 
Examiner asserted that one of ordinary skill in the art would recognize that UI elements are 
features/components/properties/content as allegedly evidenced by the providing of "features 
or functionalities to the UI application 42 such as 'Albert the Boss', 'Bert the manager', 
'Cathy the underling', 'Current Salary', 'Employee', etc." In particular, Applicant submits 
that Hayton et al. fails to teach or suggest providing a feature to a consumer application, 
requesting a feature matching a consumer interest from an application interworking 
framework, and/or a provider application where an interface is provided for the provider 
application and a consumer application such that a feature interest is matched with a feature 
from the provider application. Moreover, the Examiner's reliance on examples of 
content/objects that would be displayed in an application is misplaced. 

Hayton et al. is directed to a system and method of providing, e.g., remote access to 
an application. That is, Hayton et al. teaches providing a user-interface (UI) portion of an 
application to either the same machine on which the application is executing, or on another 
machine remote from the machine executing the application. (See, e.g., Abstract and Column 
2, lines 44-52). A user that is, e.g., customizing a UI 42, such as a web page, may choose UI 
elements 46 and associate those chosen UI elements 46 with one or more properties of an 
application component 34 by indicating one or more property paths. (See, e.g., Figures 1-4 
and Column 11, lines 3-15). Additionally, Hayton et al. suggests that an application 26 
(which includes, e.g., the application components 34), can create or delete properties. (See, 
e.g., Column 12, lines 44-50). Hence, Hayton et al. is merely directed to a single application 
(e.g., the server application 26) that has a client UI 42 which can be "customized" with 
various UI elements 46. Moreover, Applicant submits that Hayton et al. is clearly directed to 

reads on the limitation of claim 1 1 requiring integrating a new consumer application into a device as if part of 
an original group of software applications for the device. 

-7- 

CHIC_3505622.1 



Atty. Dkt. No. 037145-0901 



a "development" environment, where users can, e.g., "develop" the appearance of a web page 
or employee salary application. (See, e.g., Figure 4 and 5, Column 9, lines 19-29, and 
Column 10, lines 55-65). 

In contrast to the above-teachings of Hayton et al., various embodiments disclosed in 
independent claims 1,18, and 17 of the present application, require adding features to a 
consumer application, where the feature matches that which a consumer wishes to have. As 
described above, Hayton et al. merely teaches adding a UI element to the UI 42, not a feature 
to application 26. (See, e.g., Figure 4 and Column 20, lines 21-64). 

With regard to, e.g., claim 1, for example, the feature matching a consumer interest is 
requested from an application interworking framework. It appears from the Examiner's 
assertions that the Examiner is reading, e.g., the property connector API 22 as the claimed 
application interworking framework. {See, e.g., Column 11, lines 49-52 of Hayton et al. 
where it is described that upon execution of the property connector API 22, a UI element 46 
is mapped to an application component 34). However, nowhere in the portions of Hayton et 
al. cited by the Examiner, nor anywhere else in Hayton et al., is it taught or even 
contemplated that any request is made of the property connector API 22. Moreover, claim 1 
further requires, e.g., identifying a provider and providing a feature if the provider is 
identified. Applicant submits that nowhere in Hayton et al. is it described or otherwise 
suggested that a provider is identified. As noted above, Hayton et al. is directed to 
modifying, e.g., a UI 42, where the same server process 14/application 26 is always 
associated with the UI 42. Hence, there is no need for the system and method of Hayton et 
al. to ever "identify a provider" as required by independent claim 1 of the present application. 

In reference to claims 8 and 27, for example, both a consumer application (which, 
e.g., publishes a feature interest indicating what features a consumer application desires to 
have) and a provider application that has the feature are required. As described above, 
Hayton et al. merely teaches a single application, e.g., the server application 26. Therefore, 
Hayton et al. cannot anticipate both of the claimed consumer application and provider 
application, because again, Hayton et al. is directed merely to a single application 26 that 
may have a configurable UI 42. 
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Additionally, Applicant submits that examples such as the actual data that populates a 
UI element (such as a field/tab for indicating particular employees) is in no way analogous to 
adding an actual feature matching a consumer interest to a consumer application. Again, the 
fields showing "Albert the boss," "Berth the manager," etc. are merely indicative of actual 
data that might be displayed in a UI of an application. For example, Column 22, lines 3-5 of 
Hayton et al. characterize Figure 5 as merely depicting a "screenshot" of a page already being 
used in conjunction with an executing application, nothing more. As another example, 
Column 11, lines 15-19 of Hayton et al. describe that "[T]he UI element 46 can be, for 
example, an input box for textual or numerical input and display of a value of a property 38." 

Further still, Hayton et al. at Column 20, lines 12-20 clearly teach that, e.g., Figure 4 
is an "embodiment of a screenshot 128 produced by the page interface 112 (FIG. 2) (e.g., an 
HTML editor ) that helps a user generate a UI 42' at build time according to the invention." 
(emphasis added). Hayton et al. goes on to describe that a "palette" 134 is provided to show 
what available "predefined" UI elements 78 may be used for assigning a property path to a 
UI element. Again, Hayton et al. is clearly directed to, e.g., a development application that 
allows a developer to customize an application and determine how/what objects will be 
accessed once the application is already running. Additionally, Hayton et al.'s use of the 
term "user" is indicative of a developer, not an end user. This is no way reads on the claimed 
providing of a feature (from a provider identified by consumer/end user interest and feature 
capability) and utilizing that feature at the consumer application as required in, e.g., 
independent claims 1,8, and 17 of the present application. In fact, Applicant submits that 
because Hayton et al. is directed to application building/development, Hayton et al. merely 
operates like conventional systems and methods described at, e.g., paragraph [0004] of the 
present application, where adding features to an application is limited to building an 
application using a conventional application development system. 

As to claim 2 1 of the present application, for example, storing a user interface 
element corresponding to the consumer application interest is required. As described above, 
Hayton et al. does not teach any sort of consumer application interest, only a UI element that 
a user may be interested in utilizing in the UI 42. Furthermore, the section of Hayton et al. 
that the Examiner cited to support his position, e.g., Column 16, lines 31-32, does not in any 
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way anticipate this claimed feature of the present application. That is, Column 16, lines 31- 
32 merely indicate that values corresponding to application components 34 are stored. In 
contrast, claim 21 of the present application requires that a user interface element is stored. 

Furthermore, and in contrast to the Examiner's assertions at page 5 of the outstanding 
Office Action that Hayton et al. teaches a consumer application (i.e., UI 42 of the client) and 
a provider application (i.e., application 26 of the server), Applicant submits that the Examiner 
is mischaracterizing the system and method of Hayton et al. Figure 1 of Hayton et al. 
illustrates "an embodiment of a system 10 for communicating changes between a user 
interface and an executing application, using property paths." {See, e.g., Column 9, lines 65- 
67 of Hayton et al.). That is, Figure 1 of Hayton et al. is indicative of a UI of an application 
that may be running remotely from the server providing the application, where any changes 
to, e.g., the content/data populating different fields/boxes/aspects of the UI can be determined 
by property paths. In no way does Hayton et al. suggest the existence of two applications, a 
consumer application and a provider application. The Examiner's interpretation that a UI 
reads on the claimed consumer application is simply untenable. Nothing in Hayton et al. 
suggests this interpretation. Rather and again, the UI of Hayton et al. is merely the UI 
associated with the application hosted by the server. Moreover, Applicant submits that the 
use of language distinguishing a "UI" from an "application" clearly indicates that Hayton et 
al. does not consider the UI to be an actual application, let alone a consumer application. 

Moreover, claim 2 1 requires communicating the user interface element to an 
application interworking framework. However, Hayton et al. does not teach or even 
contemplate such an operation. As evidenced by the Examiner's assertions at pages 9-10 of 
the outstanding Office Action, Hayton et al. merely teaches that the "user interface portion of 
the application can be delivered to the computer user. . ." and that the server portion 22b 
transmits to the client portion 22a any change. . ." As described above, a user of Hayton et al. 
chooses a UI element and, e.g., associates that UI element with a state of property of an 
application component. However, communicating that UI element to the property connector 
API 22 is never taught or suggested. Second, as described above, it appears that the 
Examiner has interpreted the property connector API 22 of Hayton et al. as allegedly reading 
on the claimed application interworking framework. Given this interpretation, the operation 
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involving "the server portion 22b transmits to the client portion 22a" would be analogous to 
the property connector API 22 communicating with itself because the server portion 22b and 
client portion 22a are both a part of the property connector API 22, and hence do nothing to 
support the Examiner's assertions. {See, e.g., Column 11, lines 23-30 of Hayton et al.) 

At page 4 of the outstanding Office Action, the Examiner additionally asserted that 
Hayton et al. teaches matching a consumer interest with a feature and requesting that feature 
from an application interworking framework, where a provider, if identified, provides the 
feature. The Examiner supported his position by asserting that such features are evidenced 
by a teaching in Hayton et al. that a property state is monitored and when a change is 
detected, receiving a property change event. The Examiner further asserted that, e.g., Hayton 
et al.'s teaching of initiating execution of an API upon execution of an application/requests 
delivery of a page, as well as receiving a startup argument including the name of a file 
containing the details of a UI page is further evidence in support of his position. 

Applicant emphatically disagrees with the Examiner's continued misinterpretation 
and mischaracterization of Hayton et al. First, Applicant again submits that the entirety of 
the Examiner's alleged support is described in the context of a developer developing a 
webpage using, e.g., predetermined elements. Second, the monitoring of a property state and 
the receipt of a property change event merely refer to the ability of the system and method of 
Hayton et al. to configure properties/objects/data that might populate fields or boxes in an 
application using property paths that are not static. {See, e.g., Column 11, line 24-Column 
12, line 39 of Hayton et al.) That is, applications are not tied to operating only in a "client" 
mode or a "server" mode, but can provide the effect of direct interaction via a UI even though 
the application is potentially running remotely. (See, e.g., Column 1, line 40-Column 2, line 
9, Column 2, lines 44-59, Column 3, lines 3-40 of Hayton et al.) These features of Hayton et 
al. have no relationship whatsoever with the limitations/features recited in independent 
claims 1, 8, 17, and 21 of the present application as they are merely related to determining 
how/where actual data that might populate, e.g., a web page, is gathered and delivered to the 
web page for display. 
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Even if one of the server portion 22b or the client portion 22a could be interpreted as 
being analogous to the claimed application interworking framework, Hayton et al. still fails 
to read on claim 21 of the present application. That is, Column 18, lines 57-60 of Hayton et 
al., from which the description "the server portion 22b transmits to the client portion 22a any 
change. . ." is quoted teaches that change events associated with property paths are 
communicated. Additionally, Column 18, lines 60-65 describe that in association with the 
server portion 22b transmitting change event information to the client portion 22a, the UI 
elements are notified. Therefore, Applicant again submits that if the change information 
transferred between the server portion 22b and client portion 22a is being utilized to, e.g., 
notify the UI elements, it cannot be the UI elements that are being communicated. In 
contrast, claim 2 1 requires that a user interface element is communicated to an application 
interworking framework. 

Furthermore, at pages 5-6 of the outstanding Office Action, the Examiner maintained 
that Hayton et al. allegedly teaches: 

(1) storing a user interface element corresponding to an 
application interworking framework (2) communicating the 
user interface element to an application interworking 
framework (emphasis added). 

First, Applicant submits that the Examiner has failed to properly consider the 
limitations of claim 21 . That is, referring to the Examiner's characterization of the first 
limitation at issue, the Examiner indicated that the user interface element corresponds to an 
application interworking framework. However, in actuality, claim 21 of the present 
application recites "store user interface element corresponding to the consumer application 
interest resource in a file ." 

Second, Applicant submits that a teaching in Hayton et al. indicating that upon 
execution, a property browser can obtain instantaneous values of available application 
components, properties and relationship, in no way reads on the claimed storage of a user 
interface element corresponding to a consumer application interest resource in a file, nor to 
communicating the user interface element to an application interworking framework. Again, 
all that Hayton et al. is suggesting at, e.g., Column 16, lines 23-33, is that the UI can obtain 
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the "values" of objects which are to, e.g., populate fields in the Ul/web page instance. In no 
way does Hayton et al. teach any sort of storing a user interface element as recited in claim 
21 corresponding to a consumer application interest resource in a file, and communicating 
that user interface element to an application interworking framework. 

Third, Applicant submits that the Examiner's remaining assertions fail to support the 
Examiner's assertions that Hayton et al. teaches each and every limitation recited in 
independent claims 1, 8, 17, and 21 of the present application for at least the same reasons 
above. That is, the Examiner's assertions are based upon a clear mischaracterization of 
Hayton et al. described above. Therefore, the Examiner's alleged support for his position(s) 
found in Hayton et al. do not actually read on the claimed limitations of independent claims 
1, 8, 17, and 21 of the present application. 

Applicant further submits that the Examiner has mischaracterized the teachings of 
Hayton et al. with respect to dependent claims 2, 3, 5-7, 9-16, 18-20, 22, and 23 of the 
present application. For example and with respect to, e.g., dependent claims 2, 12, and 18, 
the Examiner asserted that the claimed limitation of "using generic parameter in application 
interworking framework application programming interfaces (API)" is taught by Hayton et 
al. at Figure 1 and Column 11, lines 50-52. However, as noted by the Examiner at page 10 of 
the outstanding Office Action, Column 11, lines 50-52 merely teach, e.g., that the "API 22 
maps each dynamic user-interface element 46 to a property 38 of an application component 
34 using the associated property path." Applicant still cannot find or deduce where or what 
element of the quoted language of Hayton et al. is being interpreted as referring to generic 
parameters in application interworking framework application APIs. Therefore, Applicant 
respectfully requests that if the Examiner wishes to maintain this rejection, that he 
explain/point out with specificity, how the teachings of Hayton et al. are being interpreted to 
allegedly read on the claimed limitations of, e.g., claims 2, 12, and 18 of the present 
application. 

At page 7 of the outstanding Office Action, the Examiner asserted that the associated 
property path taught by Hayton et al. could be "interpreted" to be a generic parameter and 
thus, allegedly teaching mapping each dynamic user interface. Again, Applicant submits that 
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the property path of Hayton et al. is utilized for directing an application as to where/how to 
receive, e.g., object data or values, that are to populate a web page UI, for example, and in no 
way teaches or suggests the use of generic parameters. As already described above, these 
property paths are paths to particular information/values/data, and therefore cannot merely be 
generic parameters. Even if the Examiner's intent was to suggest that the "syntax" of a 
property path was somehow generic and that the actual property path itself could by 
dynamically changed, again, the property path is applicable merely to data/values that would 
populate a UI element, such as a text box. 

With regard to, e.g., claim 11, the Examiner asserted that the claimed limitation 
"wherein the new consumer application integrates into the device as if part of an original 
group of software applications for the device" is allegedly read on by Hayton et al. at Column 
10, lines 66-67. Column 10, lines 66-67 of Hayton et al., as quoted by the Examiner merely 
states that "[t]he client process 18 produces a user-interface ('UI') 42 that is displayed to a 
user." Applicant submits that producing a UI that is displayed to a user suggests nothing 
even remotely associated with integrating a new consumer application as if part of an original 
group of software applications as required by, e.g., claim 1 1 of the present application. First, 
and as described above, Hayton et al. fails to teach the integration of any new consumer 
application. Rather, Hayton et al. is directed to implementing UI elements in a UI 42. 
Second, the fact that a UI 42 is displayed indicates nothing regarding how a new application 
is integrated into an original group of applications as if it were an original part thereof. There 
is simply no language or implicit indication in Hayton et al. that suggests such a feature. 

In response to the above arguments made by Applicant in the April 24, 2008 Reply 
regarding claim 11, the Examiner asserted that 

Every application stored in a device is considered as integrated 
into the device because it is part of the device. In this case, UI 
41 is part of the device and therefore it must be integrated into 
the device with other software applications of the device. 

Again, Applicant submits that Hayton et al. fails to teach more than a single 
application which in the case of Hayton et al. is stored/hosted on a server that is possibly 
remotely located from a client. Furthermore, there is no teaching or suggestion in Hayton et 
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al. that any other application, let alone a new consumer application, is ever integrated into the 
application stored/hosted on the server. All that Hayton et al. describes is, e.g., allowing a 
developer to develop some type of UI for an end user, where data/values can be transmitted 
to a server application and displayed on a UI hosted on a client device. 

Further still, Applicant submits that the Examiner's reasoning in no way suggest that 
a new consumer application is integrated in to device as if part of an original group. As 
repeatedly argued by Applicant in previous responses, claim 1 1, for example, is directed to an 
embodiment where a new consumer application can be added to a device. The new consumer 
application will, e.g., appear and/or operate, as if it was originally a part of the device, for 
example, when the device was initially provided by an end user/configured, developed, etc. 
Applicant again directs the Examiner to paragraphs [0003]-[0004] of the present application 
where it is described that certain prior art that the present application seeks to improve upon 
includes, e.g., devices such as phones. When new features/applications are added to such 
devices, the new features/applications do not look/act like those features/applications 
originally provided by the phone manufacturer. 

Additionally, Applicant submits that because dependent claims 2, 3, 5-7, 9-16, 18-20, 
22, and 23 are dependent upon independent claims 1, 8, 17, and 21 of the present application, 
Hayton et al. fails to teach all of the required limitations recited in the dependent claims for at 
least the same reasons as discussed above with regard to, e.g., claims 1, 8, 17, and 21. 

Claim 4 was rejected under 35 U.S.C. § 103(a) as being unpatentable over Hayton et 
al. in view of International Patent Application No. WO 00/58855 (Gudmunson). 

With regard to claim 4, the Examiner correctly recognized that Hayton et al. does not 
teach the use of dynamic link libraries. However, the Examiner asserted that Gudmunson 
cures this deficiency. Applicant submits that because Gudmunson was applied by the 
Examiner solely for purpose of evidencing the use of DLLs, Gudmunson cannot cure the 
deficiencies of Hayton et al. described above. Therefore, because claim 4 depends from 
independent claim 1 of the present application, Applicant submits that the alleged 
combination of Hayton et al. and Gudmunson still fail to teach all of the required limitations 
of claim 4 for at least the same reasons as discussed above. 

-15- 

CHIC_3505622.1 



Atty. Dkt. No. 037145-0901 



Because none of the references cited by the Examiner, either separately or in 
combination with each other, teach all of the required limitations of independent claims 1,8, 
17, and 21 of the present application, Applicant submits that each of these independent 
claims are patentable over this prior art. Furthermore, because dependent claims 2-7, 9-16, 
18-20, 22, and 23 are each directly or indirectly dependent upon independent claims 1, 8, 17, 
and 21, Applicant submits that each of these claims are allowable for at least the same 
reasons as discussed above. 

Applicant believes that the present application is now in condition for allowance. 
Favorable reconsideration of the application as amended is respectfully requested. 

The Examiner is invited to contact the undersigned by telephone if it is felt that a 
telephone interview would advance the prosecution of the present application. 

The Commissioner is hereby authorized to charge any additional fees which may be 
required regarding this application under 37 C.F.R. §§ 1.16-1.17, or credit any overpayment, 
to Deposit Account No. 19-0741 . Should no proper payment be enclosed herewith, as by a 
check being in the wrong amount, unsigned, post-dated, otherwise improper or informal or 
even entirely missing or a credit card payment form being unsigned, providing incorrect 
information resulting in a rejected credit card transaction, or even entirely missing, the 
Commissioner is authorized to charge the unpaid amount to Deposit Account No. 19-0741 . 
If any extensions of time are needed for timely acceptance of papers submitted herewith, 
Applicant hereby petitions for such extension under 37 C.F.R. §1.136 and authorizes 
payment of any such extensions fees to Deposit Account No. 19-0741. 



Respectfully submitted, 



Date: October 20, 2008 



By 



/G. Peter Albert, Jr./ 



FOLEY & LARDNER LLP 
Customer Number: 30542 
Telephone: (858) 847-6735 
Facsimile: (858) 792-6773 



G. Peter Albert Jr. 
Attorney for Applicant 
Registration No. 37,268 
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